我們先前在Day2 3分鐘帶你初步認識SPA 的文章初步介紹過SPA，主要是用前端client side render的方式。另外在前兩天我們也提到了，前端可以將內容輸出成元件(component)， 然後渲染畫面(render)的行為， 今天我們來談談這些背後是如何運作的，並用實例來示範什麼是server side render與client side render。

Server side render

首先到bootstrap官網，可以看到網址列上顯示了目前造訪的網址，為了更進一步了解，我們可以使用Chrome的開發者檢查工具的Console，另外為了讓網頁跳轉時可以保留紀錄，可以在小齒輪「Preserve log」的地方打勾，接著在輸入框裡鍵入以下程式碼:

location.href

沒意外的話會在console得到下面的結果:

"https://getbootstrap.com/"

這個代表目前我們造訪的網址，location物件可以取得瀏覽器網址資訊，location.href的屬性可以取得完整網址列資訊。

接著我們選擇Documentation連結， 這時瀏覽器的網址列已經變成另一個網址，頁面內容也跟著改變了，而且看到console的紀錄多了一行跳轉紀錄如下:

Navigated to https://getbootstrap.com/docs/4.5/getting-started/introduction/

再更進階一點，我們可以進一步檢查連線的資訊，使用Chrome Devtools前往Network，找到剛剛連線Response資訊:

我們透過瀏覽器向伺服器請求的動作叫做request，從伺服器取得資料後，傳回結果的動作叫response。回顧剛剛的行為，當我們要造訪網站時，本地端透過瀏覽器，向伺服器請求資料，在伺服器找出對應的檔案，由伺服器執行並進行處理後傳回結果，成為你所看到的內容，頁面內容與資料由伺服器一氣呵成地完成，server side render就是這樣的原理。

Client side render

這邊舉Google的Gmail服務為例，一樣使用Chrome檢查，我們可以發現在切換側邊頁面時，console裡並不會顯示跳轉訊息，但網址列與內容會產生變化:

我們再進一步去看Network，可以發現不像前面server side的例子，Gmail跳轉其他分頁時，不會隨著切換頁面而重新發送完整的請求:

「咦?那麼網址和內容是怎麼產生變化的呢?」

答對了，就是用了Javascript以及HTML5 API做出變化的效果。只有第一次會向伺服器請求資源，之後網址可以動態產生變化，那麼畫面呢?也是透過前端程式算完，再呈現於畫面中，如此每次換頁都不用向後端發送請求，只有在調用資料時用非同步方式來向伺服器請求，這也是SPA的一大重點。

兩種方式優劣比較

你可能會想，既然都是一樣的結果，為什麼還需要區分兩種開發方式呢? 這邊簡單做說明，server side render在讀取頁面時，除了http檔頭資訊、html head資訊，畫面與資料也會一起全部讀出來，client side render則是第一次會進行完整請求，通常是畫面先出來，資料在讀取動畫後才出現。規模小、流量小的網站同樣方式可能感受不到太大的差別， 但只要流量一多就會顯現client side render的優勢，因為server side render會完整請求所有資源，client side render可以針對需要用到的資源以非同步來請求;理論上可以減輕伺服器負擔，也能讓使用者不必等待所有資料完整請求，進而帶來更好的使用體驗。

一定要用SPA嗎?

前面說到SPA有這麼多的優點，那是不是代表一定要使用?沒有明確答案，只能說還是得視情況而定。因為是單頁應用，內容絕大部分是放入前端程式，HTML就像一張表皮，所以SEO上較為弱勢。在開發上因為後端僅提供資料與安全性驗證，畫面與呈現邏輯都交由前端處理，所以得習慣前後端分離的開發模式。另外路由也交給前端管理，請求資料後的解析與呈現也都是前端完成，所以相較傳統開發，前端做的事情變得更多了，處理也變得更複雜，是不是一定需要用到SPA，還是得看專案架構與實際情況來決定。

若還想知道更多資訊，這邊推薦前端三十｜18. [FE] 為什麼網站要做成 SPA？SSR 的優點是什麼？閱讀。

今天到這裡結束，我們明天見!